Software development tool for ensuring links between uml models and the implementation thereof in a cobra environment

ABSTRACT

The invention consists in automatically equipping the UML implementation model from UML interface models (MA) according to a UML relation present between each class of interface and the class of implementation thereof, in addition to using said link to generate the implementation code (M 1 ) with CORBA specificity. The invention also relates to the transformation and instrumentation of a server application and also to the transformation and instrumentation of client application.

The invention relates to a software development tool for ensuring linksbetween UML models of CORBA interfaces and their implementation.

UML stands for Unified Modelling Language.

CORBA stands for Common Object Request Broker Architecture.

IDL stands for Interface Description Language.

The UML language provides efficient means for specifying softwaresystems and describing a model of these systems. Some softwareworkshops, in other words software application development tools, enablecode generation starting from the UML model.

At least two models must be defined for the development of a distributedsystem based on CORBA and according to a UML process, with one model tospecify IDL interfaces and another model to define their implementation.

Software workshops propose solutions to describe the two sorts of modelsand generate the IDL code and code implementation from these models.

But these tools cannot be used to equip the UML interface model to makea link with the UML implementation model, and the two models remaincompletely independent. This requires that an implementation code thatdoes not include specific CORBA features of the system should begenerated.

The only existing solution to create a link between the UML model of IDLinterfaces of a distributed system and the UML model of theimplementation of this system is to:

-   -   generate the interfaces IDL code from the UML model,    -   compile these interfaces with an ORB (Object Request Broker),    -   use a reverse engineering phase to obtain an UML model of the        implementation from the generated code.

The solution described above is only a partial solution to the problemsince it only links the UML models and it cannot be used to equip theUML interface model to generate an implementation code related to theseinterfaces.

Moreover, this solution depends very strongly on the quality of thereverse engineering phase starting from the generated code. Manualexecution of such a phase can guarantee good quality but it will remainfairly inefficient, and automation using a software workshop does notyet provide the required quality and requires manual feedback on themodel obtained.

Another disadvantage is due to the fact that with this solution, thereis no dependence between the interface model and the implementationmodel. Thus any changes (even minor) in the interfaces of the UML modelare difficult to transfer to the implementation model.

This invention consists firstly of automatically equipping the UMLimplementation model from the UML interface model, using a UML relationpresent between each interface class and its implementation class andsecondly to use this link to generate the implementation code with CORBAspecific features.

The invention is applicable to transformation and instrumentation of aserver application and also to transformation and instrumentation ofclient applications.

Therefore, the invention also relates to a software development tool toensure links between UML models of CORBA interfaces and clientimplementations.

Note more precisely that at least the following two models must bedefined for the development of a system of distributed objects in theCorba environment with the UML language:

-   -   a model called the analysis model in which interfaces and their        relations with other high level classes describe the        application;    -   a model called the implementation model in which all application        classes are mentioned. A large number of technical classes are        added in this model.

Therefore, according to another characteristic of the invention, it isproposed to ensure a link between the UML implementation model startingfrom the analysis model.

Note also that a “CORBA Messaging” document (contained in the CORBA 2.4specification) provides four different models to invoke an interface toa client, namely:

-   -   synchronous (or two-directional) invocation,    -   single-directional invocation,    -   asynchronous invocation with the “callback” model;    -   asynchronous invocation with the “polling” model.

Asynchronous invocations require a specific class implementation toprocess the responses.

Therefore according to the invention, it is proposed to stereotype theUML “use” relation for asynchronous invocations, between a class (ormethod) and an interface.

The UML label on this “use” relation specifies the characteristic ofthis asynchronous relation which may be “callback” or “polling”.

Thus, we will automatically construct the implementation model startingfrom the analysis model. As will be seen in the following, this willconsist of creating a class called “callback” or “polling” frominterfaces, according to CORBA 2.4 specific features and the C++language. We will also generate the corresponding code based on CORBA2.4 specific features and the C++ language.

Therefore, the purpose of the invention is a software development toolincluding means for designing UML interface objects and generating themin IDL language, characterised mainly in that it comprises:

-   -   means of designing UML implementation objects and generating the        corresponding implementation source code (C++),    -   and in that the UML interface objects and UML implementation        objects are linked as early as the design phase.

According to another characteristic, UML implementation objects and UMLinterface objects are linked by a UML relation present between eachinterface class and the corresponding implementation class, this linkbeing used to generate the implementation code with CORBA specificfeatures.

One UML interface object is the model specifying IDL (InterfaceDescription language) interfaces of a distributed system, and the otherobject defines their implementation.

This UML interface object is the analysis model in which the interfacesand their relations with other high level classes describe the clientapplication, the other object being the implementation model in whichall application classes are mentioned.

Other specific features and advantages of the invention will becomeclearer after reading the following description given as anon-limitative example with reference to the drawings, wherein:

FIG. 1 is a diagram illustrating the development tool for transformationand instrumentation of a class that implements an interface startingfrom an analysis model;

FIG. 2 diagrammatically shows the analysis model of a clientapplication;

FIG. 3 diagrammatically illustrates the development tool fortransformation and instrumentation of the client application shown inFIG. 2.

According to the invention, it is proposed to automatically equip theUML implementation model starting from the UML interface model, shown asreference MA in FIG. 1, using a UML relation present between eachinterface class and its implementation class. It is also proposed to usethis link to generate the implementation code with the CORBA specificfeatures.

As defined by the OMG (Object Management Group) in the UML for CORBAprofile, in a UML model, IDL interfaces must be described by stereotyped“CORBA” interface classes.

We will do this using a UML “realize” link (implementation link) betweenthe interfaces and the corresponding implementation classes. This linkautomatically associates implementation methods related to thedescription of the IDL interface.

For each operation defined in an IDL interface, a method with the samename and the right signature is automatically generated in thecorresponding implementation class. Two access methods are defined inthe implementation class for each attribute of an IDL interface, to setup and obtain the value of this attribute.

The invention is equally applicable to server applications and to clientapplications.

FIG. 1 shows an example of a server application. The diagram in thisFigure illustrates the transformation and instrumentation of a classthat implements a “Stream” interface starting from an analysis model MA.

According to the particular example illustrated in this Figure, the fourmethods of the “Stream Implementation” implementation class and theirsignature were added automatically using the link made between eachclass.

The solution also consists of modifying generation of the implementationclasses code to take account of CORBA specific features. For example,the generator automatically manages naming spaces, signatures andinheritance of CORBA objects from the model.

In the previous example, if the “stream” interface belongs to a CORBA“Messaging” module, the generated “StreamImplementation” class in C++inherits from the “::POA-Messaging::Stream” class.

For the model in the previous example, the generated C++ code is asdescribed in the appendix to the description.

The invention is also described later for an analysis model MA for aclient application. The analysis model for the client application isillustrated in FIG. 2, and FIG. 3 shows the transformation andinstrumentation of this client application to determine how the clientwill use the interface.

As already described, it is an analysis model in which the interfacesand their relations with other high level classes describe theapplication.

The UML “use” relation between two classes or between a method and aclass means that the method (or methods in the class) uses the denotedclass. If this denoted class is a stereotyped CORBA interface, themethod uses an interface.

Therefore, it is proposed to define how this interface will be used(synchronous or asynchronous) in the analysis model, by adding astereotype called “asynchronous” in the UML “use” relation. The“asynchronous” stereotype is used with a UML label called “callbackmodel” or “polling model”. This label indicates how the implementationmodel is built up.

There is no difference between the analysis model and the implementationmodel MI for single directional and two-directional invocations. The C++generation code must simply add the contents of the corresponding “stub”(the corresponding element), into the body of the class that uses theinterfaces.

For example, as can be seen illustrated in FIG. 2, the analysis modelshows that method m( ) of class “MyClient” uses an interface called“MyInterface”. On this link, the “asynchronous” stereotype uses the“callback model” label to specify the manner in which the “MyInterface”interface is used.

This link provides a means of automatically modifying the UML model andcreating the “ReplyHandler” class with corresponding methods as definedby the CORBA Messaging standard.

In the case of an asynchronous invocation with a “polling” model, it isproposed to add a “Corba: ami_poller” stereotype on the “use” link andit is proposed to add the “Corba: ami_callback” stereotype for the“callback” model.

With this information, the UML model contains enough information tomodify the implementation model.

According to the CORBA Messaging specific features, classes must beincluded in the new UML model. These classes are linked to theirinterface through an implementation link in order to guaranteeconsistency between the two models.

A stereotyped “CORBAInterface” class that includes a stereotyped“asynchronous” “use” relation adds an option into the IDL compiler tospecify that it must generate skeletons and specific “stubs” with theadded “Messaging” module, in order to generate the IDL code.

Classes use a “nocode” and “AMIPoller” or “AMIHandler” label, in orderto implement generation of the C++ code.

Labels are used so that generation of the C++ code can take account ofrules and syntax specified in the “CORBA Messaging mapping for C++”document published by the OMG.

APPENDIX

APPENDIX Class StreamImplantation: public : : POA-Messaging : : Stream {void read( char*_out msg, Messaging : : Stream_out replyStream) {...} ;void write( const char* msg, {...} ; void* channel() {...} ; voidchannel( const char* value, {...} ; } ;

1. Software development tool including means for designing UML interfaceobjects and generating them in IDL language, characterised in that itcomprises: means of designing UML implementation objects and generatingthe corresponding implementation source code (C++), and in that the UMLinterface objects and UML implementation objects are linked as early asthe design phase.
 2. Software development tool according to claim 1,characterised in that the UML implementation objects and the UMLinterface objects are linked by a UML relation present between eachinterface class and the corresponding implementation class, this linkbeing used to generate the implementation code with CORBA specificfeatures.
 3. Software development tool according to claim 1,characterised in that one UML interface object is the model specifyingIDL (Interface Description language) interfaces of a distributed system,and the other object defines their implementation.
 4. Softwaredevelopment tool according to claim 1, characterised in that this UMLinterface object is the analysis model in which the interfaces and theirrelations with other high level classes describe the client application,and the other object is the implementation model in which allapplication classes are mentioned.